IBIS Macromodel Task Group

Meeting date: 08 August 2017

Members (asterisk for those attending):
ANSYS:                        Dan Dvorscak
                            * Curtis Clark
Broadcom (Avago):             Xingdong Dai
                            * Bob Miller
Cadence Design Systems:     * Ambrish Varma
                              Brad Brim
                              Kumar Keshavan
                              Ken Willis
eASIC:                        David Banas
                              Marc Kowalski
Ericsson:                     Anders Ekholm
GlobalFoundries:              Steve Parker
IBM                           Luis Armenta
                              Trevor Timpane
Intel:                        Michael Mirmak
Keysight Technologies:        Fangyi Rao
                            * Radek Biernacki
                              Ming Yan
Maxim Integrated Products:    Hassan Rafat
Mentor, A Siemens Business:   John Angulo
                            * Arpad Muranyi
Micron Technology:          * Randy Wolff
                              Justin Butterfield
SiSoft:                     * Walter Katz
                              Todd Westerhoff
                            * Mike LaBonte
Synopsys:                     Rita Horner
                              Kevin Li
Teraspeed Consulting Group:   Scott McMorrow
Teraspeed Labs:             * Bob Ross
TI:                           Alfred Chong


The meeting was led by Arpad Muranyi.

--------------------------------------------------------------------------------
Opens:
- Arpad noted that Curtis had informed him that he would not be able to attend
  the meetings on August 15th and August 29th.  Arpad said he would need a
  volunteer to take minutes at those meetings.
  
- Bob Ross noted that he would be producing a BIRD191.2 to address some
  editorial comments he had received from Michael Mirmak for BIRD191.1.
  
- Arpad noted that he had sent an email regarding a potential logical
  inconsistency in BIRD189, and we might discuss it here time permitting.  But
  it will likely be discussed in the next Interconnect meeting.
         
-------------
Review of ARs:

- Mike L. to post BIRD 191.1 draft 2 to the ATM archives.
  - Done.
  
- Ambrish to draft a proposed sentence to add to the [External Model] section
  as part of BIRD191.1 and send it to Bob R.
  - Done.

- Bob R. to create BIRD 191.1 draft 3 with Ambrish's sentence and submit it
  to the Open Forum as BIRD191.1.
  - Done.

- Walter and Arpad to modify the current BIRD158.6 draft to make it compatible
  with BIRD189.
  - Done.

- Mike L. to post Walter's "BIRD166 - BIRD190 Summary" to the ATM archives.
  - Done.

--------------------------
Call for patent disclosure:

- None.

-------------------------
Review of Meeting Minutes:

- Arpad: Does anyone have any comments or corrections? [none]
- Mike L.: Motion to approve the minutes.
- Walter: Second.
- Arpad: Anyone opposed? [none]

-------------
New Discussion:

BIRD166.4:
- Discussion: Arpad noted that BIRD166 and BIRD190 had been tabled in ATM
  previously.  However, in last Friday's Open Forum meeting the newly submitted
  BIRD166.4 had been introduced, and the Open Forum had decided to send it back
  to ATM for further discussion.  Walter first confirmed that BIRD 190 was still
  tabled.  Walter then motioned to table BIRD166.4.  Bob Ross seconded.  No one
  opposed.  Arpad noted that we could always entertain motions to untable these
  in the future.
  
- BIRD158.6:
- Arpad: I sent out an "AM2" update of draft 2 that contained Walter's input to
         my original "AM" version.  ("AM2" is the suffix of the filename)
  - Radek recently sent a reply email with his feedback.
  - [sharing Radek's email]
- Radek: In response to Arpad's comments I created some new diagrams.
  - New Tx diagram:
    - Arpad had properly noted that the sources shown in the Tx diagram weren't
      really DC sources.  I had only used them to show the voltage levels that
      corresponded to logic 0 and logic 1.
    - The Tx diagram now shows voltages on the left as "Vp" and "Vn".
    - Vp and Vn are still defined in the text below the figure in terms of the
      AMI parameter Tx_V and the logic levels.
    - I disagree with the idea of showing Tx_V directly in the diagram, because
      the voltage levels also depend on the state information.
  - We should also discuss the default value of Ts4file_Boundary, which Arpad
    changed in his version.
    
- Discussion: Bob Ross noted that the "buffer terminals" text between terminals
  2 and 4 on the Tx diagram could also be "pad terminals" or "pin terminals"
  depending on the value of Ts4file_Boundary.  Radek and Arpad said they thought
  it was clear enough with one diagram, and we need not demonstrate all cases.
  Bob Ross suggested the text in the Tx and Rx figures could be changed to state
  buffer terminals or pad terminals or pin terminals.  Radek agreed with this
  suggested change.  The group agreed that the single end-to-end figure was still
  sufficient.
  
  Arpad noted that he still preferred to have the source voltage values in the
  Tx figure shown directly in terms of Tx_V.  He said he felt it was unnecessary
  to introduce the intermediate values Vp and Vn and define them in the text
  below, though he acknowledged the figure might get more cluttered since the
  state based information would have to be in the figure.  Curtis and Walter
  said they felt Radek's approach was fine.  Arpad said that his change was
  not worth pursuing if no one else felt it was necessary.  The group decided
  to leave the figure as Radek had prepared it.
  
  Radek noted that he thought Bob Miller's original comments had preferred
  "pad" as the default value of Ts4file_Boundary.  Walter noted that in practice
  the Ts4file did typically include the buffer and the on-die interconnect.
  Bob Miller agreed with Radek and Walter.  Arpad noted that he had changed the
  default value of Ts4file_Boundary to make it consistent with the following
  statement in the text of the BIRD (AM2 version):
      Typically, the Touchstone file data specified here will be used to
      describe only the analog behavior of the buffer itself, excluding the
      effects of the package and/or the on-die interconnect, as illustrated
      in the following figure.
  Arpad and Radek agreed that the solution was to return the default value
  of Ts4file_Boundary to pad and reword the sentence to indicate that the
  Touchstone file data typically described the analog buffer and the on-die
  interconnect.
  
  Bob Ross asked if this BIRD interacted with BIRD189.  He noted that IBIS 6.1
  used the term "Die" to mean die pad, and asked if the buffer, pad, pin
  terms in BIRD158 were fully defined and were consistent with BIRD189.  Arpad
  noted that BIRD158 defines "buffer", "pad", or "pin" as the possible values
  for Ts4file_Boundary.  He said we might just need a few sentences to explain
  the meaning of the three possible values (e.g., that the "pad" value for
  Ts4file_Boundary is the same location as "Die" in IBIS 6.1).  Walter suggested
  any definitions make it clear that:
     buffer - is the location where the buffer touches the on-die interconnect.
              If there's no on-die interconnect then that's the die pad.
     pad - is the point where the Silicon meets the package.
     pin - is the point where the pin touches the board.
  Walter said these BIRD158 locations were consistent with BIRD189's.
     
  Radek noted that BIRD158 had started long before BIRD189 existed.  We now
  had to adjust the text to reflect that it works with BIRD189.  He noted that
  prior to BIRD189 (i.e., currently), the IBIS package model was typically not
  used because such models had been insufficient.  He said he felt we needed to
  keep the current approach, i.e., users employing package models distributed
  outside of IBIS, clearly stated as an option in the BIRD text.  He said this
  was the point on which he disagreed with Arpad's text.  Radek's position,
  on one extreme, was that the EDA tool won't automatically include any package
  model from the IBIS file, with the understanding that the EDA tool could
  always present the user with options to do so.  He felt Arpad's position, on
  the other extreme, was that the EDA tool should automatically include the IBIS
  package model if the Ts4file_Boundary were buffer or pad, though the tool
  could offer the user the option to use something else.  He felt this was
  still a sticking point.  Radek noted that he now thought it might be a good
  idea to provide an additional parameter to allow the model maker to specify
  more information about what/how/when any package model from the IBIS file
  should be employed by the EDA tool.  Walter noted that he agreed with Arpad in
  this case.  He said, now that BIRD189 allowed model makers to provide proper
  package models in IBIS, we should no longer be worried about the current
  practice.  For any future models, the model maker should employ BIRD189 and
  avoid any ambiguities about what was contained in various portions of the
  package modeling.
  
- Arpad: Could I give Radek the AR to update my AM2 version by updating the
         drawings (including Bob R.'s buffer terminal or pad terminal or pin
         terminal suggestion), changing the Ts4file_Boundary default back to
         pad, and changing the text of the corresponding sentence?
- Radek: Yes, and I will also feel free to add a way for the model maker to give
         more of a description of the contents/usage of the package model.

- Mike L.: Motion to adjourn.
- Curtis: Second. 
- Arpad: Thank you all for joining.

AR: Radek to update the AM2 version of BIRD158.6 draft 2 to create a draft 3.

-------------
Next meeting: 15 August 2017 12:00pm PT
-------------

IBIS Interconnect SPICE Wish List:

1) Simulator directives
